Testen einer komplexen sicherheitskritischen ADAS-Funktion unter erschwerten Bedingungen

Um Fortschritte in der immer weiter fortschreitenden Automatisierung des autonomen Fahrens erreichen zu können, müssen immer komplexer werdende Fahrerassistenzfunktionen in immer komplexer werdenden Umgebungen verifiziert und validiert werden, bevor sie eine allgemeine Straßenfreigabe bekommen können.

Aufgrund vieler komplexer Randbedingungen gestaltet sich die Verifikation (im wesentlichen dynamische Tests) von sicherheitskritischen Fahrerassistenzfunktionen schwierig und anspruchsvoll.
Unser Vortrag handelt von den Herausforderungen und deren erfolgreich angewendete Lösungsansätzen, die sich in unserem realen Projekt ergeben haben.
Fast alle zum Testen gehörende Themen und Sachverhalte mussten individuell gezielt bewertet und für die sich dabei resultierenden Herausforderungen Lösungen gefunden werden.

Beispiele:

Testkomplexität

•    Hohe Anzahl verschiedenster Sensoren (ca. 7 - 10) mit unterschiedlichen Blickwinkeln und Reichweiten    
•     Noch höhere Anzahl von Signalen (ca. 800)
•     Berücksichtigung von (Nicht-) Vermengung unterschiedlicher Integrity-Level (QM und ASIL) von Signalen in der Fusion und daraus sich ergebende Notwendigkeit von FFI-Analysen
•     Umgang mit „Big Data“ im Testen von ADAS Funktionen

Testmethoden

•     In der Software sind Sensor-Fehler oft nicht erkennbar
•     Die zu bewertenden sicherheitskritischen Situationen sind sehr komplex (s.a. *SOTIF*)

Testtools und -Simulation

•     Simulationstools sind i.d.R. nicht qualifiziert oder nicht verfügbar
•     Da es sich beim automatisierten Fahren um Neuland handelt, gibt es kaum Referenzsysteme
•     Wo können / müssen Tools qualifiziert werden?
  •  Z.B.: Compile
  • Wie können Back-to-back Tests hier helfen?

Testdaten

• Es gibt keine vollständigen realen Testdaten
• Entwicklung nur interaktiv möglich
  • Die manuelle Erzeugung von Testvektoren ist sehr aufwendig oder nur für systematische situationsbedingte Tests machbar
  • Realdaten nur über Testfahrten erzeugbar (hohe Datenmengen/ komplexes Timing)
  • Realdaten Aufzeichnung teilweise problematisch (DSGVO)
  • Daten Aufzeichnung extrem schwierig (Datenmenge / Timing)
  • Herausforderungen bei der Entwicklung und Nutzung von Spezialhardware zur Datenaufzeichnung (Datenraten / Latenzen)

Testanforderungen

• Sicherheitsanforderungen des OEMs sind i.d.R. zu Beginn des Projekts nicht vollständig
• Komplexität der Permutationen von Testdaten nur handhabbar über Daten-Recordings
  • Fehler anderer Sensor oder Kartendaten nicht bekannt
  • Anforderungen im Endsystem zum Teil nicht tastbar (algorithmische Fehler)
  • Definition von Fehlern schwierig (SOTIF vs. ISO)

Bsp.: Gültige Wertebereiche von Signalen vs. Einschwingvorgänge von Algorithmen

Testautomatisierung

• selbst mit Realdaten zeitaufwendig (wie viel km an Testdaten sind ausreichend?)
• Nicht alle Anforderungen testbar (Review?) – oder nur im Verbund
• 10000 Fahrstunden sind mehr wert als synthetische Tests. Aber bei Safety - wie kann man diese Datenmengen als korrekt ansehen?
  • Fahrszenendatenbank zum Regressionstesting
  • Prozessierungsdauer vs. Änderungsfrequenz der SW
  • Möglichkeiten der Skalierung und Prozessbeschleunigung
• Methoden zur effizienten Regressionsteststrategie durch Nutzung von „Big Data“ (Anwendungsmöglichkeiten / Realisierung)
  • Skalierung und „Speed Up“ Möglichkeiten
  • „Hot Spot“ Analysen
•  Automatisierte Annotation und Durchsuchung von Test-Vektoren um bestimmte Szenarien zu testen
•  Kontinuierliche Überwachung nicht funktionaler Anforderungen (Memory Consumption / Runtime / Memory Protection)
•  Automatisiertes Tracing von Tests zu Anforderungen

Testplattform

• Tests auf Zielhardware ohne komplettes Endsystem, da im Endsystem teilweise nicht mehr alle Anforderungen aufgrund fehlender Testschnittstellen testbar sind
  • Algorithmische Fehler über Fault Injection
  • Function Tracing
• Analyse von fehlschlagenden Tests sehr aufwändig
• Zusammenspiel der unter Test stehenden Komponente mit vielen weiteren Komponenten ist sehr komplex für systematisches Testen
• Spezial Debugging-Hardware zum Testen?
  • Teilweise sehr teuer und nur bedingt möglich
  • Bestimmte Anforderungen nur im Dauerbetrieb testbar
  • „Verschwimmend“: Hardware Software - abstrakte Sensoren
• Debugging unheimlich schwierig
• Umgang mit Wahrscheinlichkeits-basierten Algorithmen sehr herausfordernd im Zusammenspiel mit Safety-Anforderungen – Schritt zu KI-Algorithmen noch herausfordernder

Vorgestellte Themen

• Komplexität in der Verifikation von ADAS-Funktionen
• Wie geht man mit den Herausforderungen um?
• Was bedeutet SW Safety?
• Wie sieht es mit der Performance aus?
• Welche Lösungsansätze (Tools und Methoden) haben wir verfolgt?

Die Präsentation handelt von einem realen Projekt.

zurück zum Programm